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ABSTRACT 



This invention relates to an object-oriented system and 
method for easily and rapidly distributing medical images 
from existing picture and report storage systems to a plu- 
rality of heterogeneous client workstations. The system 
includes one or more interface engines, for providing image 
objects with uniform structure regardless of the type of 
existing system on which they are stored, and image server 
middleware, for managing the distribution of image objects. 
The system also includes a security object server, for autho- 
rizing user access to the image distribution system and to 
particular objects, a personalization object server, for pro- 
viding user interface preferences and client workstation 
capabilities, and a web server, for downloading initial access 
pages and user interface components. The system imple- 
ments a method for medical image distribution according to 
which image data stored in existing picture storage systems 
is first converted into a uniformly structured image objects 
before being composed for downloading to client worksta- 
tions for user viewing. The system and method of this 
invention are easily extensible both for added function and 
for added performance. The system and method of this 
invention are preferably implemented according to CORBA 
standards. 

23 Claims, 4 Drawing Sheets 
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COMPUTER-BASED MEDICAL IMAGE 
DISTRIBUTION SYSTEM AND METHOD 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a computer system and 
method for enabling uniform access to and ready distribu- 
tion of medical images and associated records in electronic 
form via a network, such as an intranet or the Internet, from 
multiple heterogenous and incompatible existing server sys- 
tems. 

2. Description of the Related Art 

Handling of medical images, and of associated medical 
information, has been profoundly changed by the impact of 
digital and computer technologies. But in the current state of 
the art, these technologies have not resulted in uniform 
system by which a user can readily access medical image 
information from multiple and incompatible existing server 
systems. 

Picture Archiving and Communication and Radiology Infor- 
mation Systems 

Medical images are currently acquired by diverse imaging 
technologies and methods, including, for example, such 
methods as X-ray imaging, computed X-ray tomography, 
radioisotope emission imaging, computed emission 
tomography, magnetic resonance imaging, ultrasound 
imaging, and so forth. With increasing prevalence, medical 
images acquired by these and other methods are being 
directly acquired in or converted into digital form for storage 
and retrieval. 

Current computer systems for storage and retrieval of 
such digital medical images (generically named Picture 
Archiving and Communication, or "PAC", systems), typi- 
cally have large amounts of digital storage, a processor for 
storing and indexing images, and user workstations attached 
directly, or across a network, to the PAC systems for image 
display. These systems have usually been designed with a 
client-server, or two-tiered, structures. In such structures, the 
workstations, acting on the second-tier as image clients, run 
specific software designed for interacting with a specific 
PAC system, acting on the first tier as an image server, in 
order to obtain and display images. The specific server 
software on the PAC system is designed to accept and 
respond only to the specific requests from the corresponding 
image-clients. 

Therefore, two different PAC systems having different 
client and server software cannot be expected to be able to 
exchange image data. A user needing to access multiple 
different PAC system needs a specific client suited for each 
PAC server system. 

Similarly text interpreting medical image and associated 
patient information is being transcribed into or captured 
directly in digital form and stored on server systems 
(generically named Radiology Information, or "RI", 
systems). RI systems, like PAC systems, are also usually 
designed as client-server, or two-tiered, systems with user 
workstations running specific client software that interacts 
only with specific server software on the RI system. 

Also like PAC system, two different RI systems cannot be 
expected to be able to exchange image data, and a user needs 
multiple specific clients suited for each RI server system of 
interest. Indeed, a PAC system is even less likely to be able 
to exchange data in any fashion at all with an RI system. 

Other specialized information systems exist in the health- 
care environment. For example, there are specialized 
departmental-scale systems, such as those for storing and 
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retrieving diagnostic cardiology images, for interfacing to 
and reporting results from laboratory instruments, for phar- 
macy management, and so forth. There are also institution- 
scale Hospital Information ("HI") systems, such as those for 

5 patient financial and billing, or for patient admissions, 
discharge, and transfer ("ADT'). 

All of these systems, like PAC and RI systems, comprise 
specialized software designed for the particular application 
and also often structured in a client -sever, two-tiered, archi- 

10 tecture. And like PAC and RI systems, these departmental - 
or institution-scale information systems (e.g., HI systems) 
present in the health-care environment cannot be expected to 
exchange data or to interoperate. Users typically require a 
separate client to interface each of these systems. 

15 Incompatibility Problems Associated with Current Standard 
Efforts 

One approach to solving these incompatibilities is stan- 
dardization of messages or interfaces. However, standard- 
ization alone is at best only a partial solution to solving 

20 system incompatibilities and to providing uniform data 
access. For example, the Digital Imaging and Communica- 
tions in Medicine ("DICOM") is one standard relevant to 
medical image distribution. DICOM has been developed and 
promoted by the American College of Radiology/National 

25 Equipment Manufacturers Association (ACR/NEMA), and 
aims to standardize formats for exchange of image data in 
PAC systems by defining a standard set of basic and com- 
posite data types along with a standard set of requests 
involving those data types, all of which are representative of 

30 the imaging activities in a radiology department. 
Accordingly, a single workstation with a DICOM- 
conforming client can expect some success in accessing 
multiple PAC systems, also DICOM-conforming, and the 
multiple DICOM-conforming PAC systems can themselves 

35 expect some success in exchanging image data. Individual 
variations in the details of DICOM-conformance may defeat 
interoperability or data interchange. 

A similar standard applicable to RI systems is HL7, a 
standard that aims to define formats for electronic data 

40 interchange in health-care environments, In particular, HL7 
defines message formats for exchange of information relat- 
ing to a broad range of health-care activities, including 
patient admissions, discharges, transfers, patient queries, 
billing, clinical observations, and orders, and eventually 

45 patient medical records generally. Because of such broad 
goals, HL7 is even less of a true "plug-and-play" standard 
than is DICOM. In other words, two systems, although 
conforming to HL7, are likely, nevertheless, not be able to 
exchange requests and data. Therefore, a single user may 

50 still require multiple clients in order to access multiple RI 
systems, even though they are all HL7 conforming. 

Yet a further problem is due to the multiple standards, 
such as DICOM and HL7 in radiology, present in the 
health-care environment. Even if they individually achieve 

55 plug-and-play interoperability, and not all do, the various 
standards do not interoperate for data interchange among 
themselves. For example, even within one radiology 
department, a DICOM-conforming PAC system cannot 
exchange requests or data with an HL7-conforming RI 

60 system. Although, the multiple health-care data exchange 
standards may reduce system incompatibilities within their 
individual scopes, as a collection they do not achieve 
reduced system incompatibilities outside across their scopes 
as a whole within a health-care institution generally. 

65 Therefore, the current state of the art in medical image 
distribution faces daunting problems due to a lack of uni- 
form access to and interchange of medical images stored in 
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various different PAC systems, and also to a tack of uniform interface for receiving medical image requests from a user 

access to and interchange of associated medical interpretive and for displaying medical image objects to the user; and 

text information stored in RI and other health-care systems. wherein said one or more computer systems are configured 

What is needed, therefore, is a method and system by with one or more interface engines, each said interface 

which a user can uniformly and rapidly access medical 5 engine for retrieving medical image data from one or more 

image data without regard to the boundaries of existing existm g stora 8e systems and for presenting retrieved medi- 

PAC, RI, or other health-care systems. Further, since health- c £ image data as medical image objects with a uniform 

care personal often do not have fixed work locations, need- object-oriented structure, and one or more image object 

ing to respond to health-care problems promptly wherever coordinators for receiving medical muge requests transmit- 

they happen to be, such uniform and rapid access should 10 ted & om onc of said graphical interfaces for obtaining 

allow users to access medical image information from many medl f cal ma S e ob J ectS m ^"f 0 ™ object-oriented struc- 

diverse local or remote workstations. And since patients also «»« from said one or more interface engines, for composing 

move, such uniform access should provide medical image sald f medlca l ob ^f f°r chsplay by said graphical 

information between separate health-care institutions. m L terface > and for tnnamtting said composed medical image 

15 objects to the requesting graphical interlace. 

SUMMARY OF THE INVENTION ^ n a nrst as P ect » tne first embodiment also includes that 

said one or more computer systems are further configured 

It is an object of the present invention to provide a ^th one or more report interface engines for retrieving 
solution to the above problems of the incompatibilities of medical report data associated with said medical image data 
existing PAC and RI systems and of lack of uniformity of ^ f rom one or more existing storage systems and for present- 
access to their stored image data. This object is achieved by mg ret rieved medical report data as medical report objects 
novel and innovative application of computer middleware ^th a uniform object-oriented structure, and wherein said 
technologies to create a three-tiered information system one or more i ma ge object coordinators further receive 
architecture. The resulting system achieves surprising mc dical report requests associated with said medical image 
benefits, including scalability in performance and in func- data transmitted from one of said graphical interfaces, obtain 
tion. Hardware can easily be added or removed to achieve medical report objects in said uniform object-oriented struc- 
necessary performance at low cost; additional processing lure f rom G ne or more report interface engines, compose said 
modules can be easily added to achieve uniform access to me dical report objects for display by said graphical 
additional image data formats, or even to additional health- interface, and transmit said composed medical report objects 
care client-server systems. 3Q to the requesting graphical interface. 

The middleware software of the present invention which In a second aspect, the first embodiment also includes: 

processes data and requests to existing PAC and RI systems that said one or more computer systems are further config- 

into a common format and structure. Medical images and ured with a plurality of image object coordinators; that said 

associated medical information, and indeed general patient one or more computer systems are further configured with 

data, can then be made uniformly available to user work- 35 0 ne or more security object servers for checking the autho- 

stations. A single workstation can access data from a diverse rization of said user to access the medical image distribution 

range of prior-art PAC and RI systems by running single system and to access requested image objects; that said one 

client software which need only interact with the provided 0 r more computer systems are further configured with one or 

common format and structure. Further, existing PAC and RI more personalization object servers for providing to said 

systems can efficiently exchange data through the medium 4Q image object coordinator information for composing said 

of this common format and structure. image objects according to interface preferences of the user 

Generally, the system includes one of more interface and according to capabilities of the client workstation; that 

engines, for providing image objects with uniform structure said one or more computer systems are further configured 

regardless of the type of existing system on which they are with one or more web servers for downloading access-data 

stored, and image server middleware, for managing the 45 forms and object-oriented graphical interface modules to 

distribution of image objects. The system also includes a client workstations; and that said one or more computer 

security object server, for authorizing user access to the systems are further configured with infrastructure modules 

image distribution system and to particular objects, a per- of a distributed object system. 

sonalization object server, for providing user interface pref- In a third aspect, the first embodiment also includes that 

erences and client workstation capabilities, and a web server, 50 said medical image data comprises radiology image data or 

for downloading initial access pages and user interface cardiology image data. 

components. The system implements a method for medical i n a fourth aspect, the first embodiment also includes: that 
image distribution according to which image data stored in said one or more computer systems are further configured 
existing picture storage systems is first converted into a with one or more cardiology interface engines for retrieving 
uniformly structured image objects before being composed 55 cardiology image data from one or more existing storage 
for downloading to client workstations for user viewing. The systems and for presenting retrieved cardiology image data 
system and method of this invention are easily extensible as cardiology image objects with a uniform object-oriented 
both for added function and for added performance. The structure; and said one or more computer systems are further 
system and method of this invention are preferably imple- configured with one or more cardiology image object coor- 
mented according to CORBA standards. dinators for receiving cardiology image requests transmitted 
In a first embodiment, this invention includes a medical from one of said graphical interfaces, for obtaining cardi- 
image distribution system for distributing medical images ology image objects in said uniform object-oriented struc- 
from one or more existing storage systems to a plurality of hire from said one or more cardiology interface engines, for 
network-attached client workstations, said medical image composing said cardiology image objects for display by said 
distribution system comprising one or more computer 65 graphical interface, and for transmitting said composed 
systems, and wherein each said network-attached client cardiology image objects to the requesting graphical inter- 
workstation is configured with an object-oriented graphical face. Further in the fourth aspect, the first embodiment also 
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includes that the system further comprises a middleware Distributed Object Infrastructure 

database for storing persistent data comprising definitions of middleware software for medical image distribution 

said uniform object-oriented structures of said cardiology according to the present invention is structured according 

image objects. principles of distributed object-oriented programming. 

In a fifth aspect, the first embodiment also includes that 5 Object-oriented programming, generally, as is well-known 

the system further comprising a middleware database for to those of skill in the art, structures programs into objects, 

storing persistent data and objects and wherein said middle- each of which is a self-contained collection of data and of 

ware database stores definitions of said uniform object- methods which act on the data. Program execution occurs as 

oriented structures of said medical image objects. cIient °^ QCts make requests of and receiving data from 

, * . . , j . 10 server objects. 

In a sixth aspect, the first embodiment also includes that Distributed object-oriented programming includes infra- 
said one or more computer systems are further configured &{mcUjT& permiuing) inter alkj client objects WTVtT 
with one or more additional interf ace engmes, for presenting iQ reside> indiscriminately ^ transparently, on one 
additional medical data retrieved from existing systems as uter or on ^ mni com p U ters, even different heterog- 
additional medical data objects with a uniform object- eQous uleK> preferably, there can be more than one 
oriented structure, and one or more additional object scrycr bk of ndi t0 a part i cu lar client request 
coordinators, for coordinating transmission of additional ^ {hQ ORR nsible for which XTVtT is t0 
medical data objects to requesting graphical interfaces; and nd tQ each rticular clicnt rcquest ^ infrastructure 
wherein said additional medical data comprises pharmacy typicaUy ^ object requegt broker ((<0Rir) 
data or medical laboratory data. ^ component) which ^ prcserjt on thc different computers and 

In a second embodiment the invention includes a method ^ responsible for transparently managing, locating, and 
for medical image distribution from one or more existing communicating between client and server objects, 
image storage systems to a user at a client workstation invention is equally adaptable to the various corn- 
comprising: obtaining a user request for a medical image; merc ially available distributed object-oriented computing 
obtaining image data for the requested medical image from M infrastructures. Such infrastructures are preferred if they 
one of said existing image storage systems; converting said conform to the CORBA family of standards of the Object 
image data into one or more image objects having a uniform Management Group, Inc. ("OMG") (Newton, Mass.; and 
object-oriented structure; composing said one or more http://www.omg.org). Such commercial infrastructures are 
image-object according to user preferences and client work- available from, inter alia, Borland, Inc. (Scotts Valley, 
station capabilities; and displaying said composed one or 3Q Calif.) and from I0NA Technologies, Ltd. (Dubhn,IrelanaO. 
more image objects to the user. Whtre all computing systems run one of the Windows™ 

In a first aspect, the second embodiment also includes, operating systems from Microsoft Corp., this invention is 

prior to the step of obtaining image data, steps of checking also adaptable to the Component Object Model from that 

identification provided by the user to authorize the user to vendor, 

obtain medical images and of checking the authorization of 35 A distributed object infrastructure conforming to CORBA 

the user to access the requested medical image object. includes at least both an Interface Definition Language 

In a second aspect, the second embodiment also includes, ("IDL") omplementation and an ORB. The IDLis a uniform, 

prior to the step of obtaining image data, a step of accessing declarative language for defining all object interfaces in the 

a master patient index for patient identification. middleware. The ORB is responsible for activating one or 

In a third aspect, the second embodiment also includes, 40 more instances of server objects, routing requests and 
prior to the step of obtaining a user request, a step of responses between client objects and server objects, trans- 
downloading graphical interface modules to the client work- parently managing all communication details of request 
station. routing, providing for object persistence and for object 

replication for reliatility or performance. The ORBs resident 

BRIEF DESCRIPTION OF THE DRAWING 45 on the various computers forming a system according to this 

Other objects, features and advantages of the present invention preferably communicate among themselves for 

invention will become apparent upon perusal of the follow- request routing according to the Internet Interorb Protocol 

ing detailed description when taken in conjunction with the ("HOP"), which is an implementation of the generalized 

appended drawing, wherein: ^ TOth protocol using the TCP/IP communications protocol 

n„ - .« . 4 , c t „ , of M • 50 suite widely available on, for example, the Internet and 

FIG. 1 illustrates an embodiment of a computer system in •*•/♦* J a ™dba , 

, ... . . . private intranets. A preferred CORBA implementation 

accordance with the present invention .1, , .u- . jcjl PAniiA r> 

r includes relevant object servers defined by CORBA Com- 

FTG. 2 illustrates an embodiment of a software architec- mon Services and Common Facilities standards. Implemen- 

ture for the middleware of the present invention; tations of IDL _ denned object interfaces are preferably coded 

HG. 3 illustrates an embodiment of the middleware 5S m q c++ ^ or j ava ® t 

database in accordance with the present invention; and Although the following description of the preferred 

FIG. 4 illustrates an embodiment of user request process- embodiment conforms to the CORBA family of distributed 

ing in accordance with the present invention. object standards, it will be readily apparent to one of skill in 

DETAILED DESCRIPTION OF THE fin f e a " ^ Mn ' T^T^ t ^ ."TT ^ 

PREFERRED EMBODIMENTS 60 f °™ t0 °* er ^f^' dlStribl ? d T u *\ , 

The hardware and software architectures described in the 

The medical image server middleware is built upon a following sections can be readily understood in view of the 

distributed object infrastructure, which is described next. In preceding description of distributed object systems, 

view of the capabilities of this infrastructure, hardware and „ , , „ „ , ... 

software architectures of the middleware are described fol- 65 Medlcal Ima S c Scrvcr Hardware Architecture 

lowing. Finally, details of the middleware databases and Referring now to FIG. 1, there is shown exemplary 

request processing procedure are described. embodiment 10 of a medical image distribution system 
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according to the present invention. The basic three-tier uniform for all attached PAC systems, and which are acces- 
architecture of this system is apparent from this figure. In the sible according to the standard CORBA/IIOP protocol, 
first tier are existing medical image information systems, Accordingly, the specialized details of the RI system are 
represented generally as system 14 at Hospital 1, system 16 hidden from a client object, which sees only uniform report 
at Hospital 2, and so forth, which currently store medical $ object interfaces regardless of the details of the RI system, 
images and associated information. Also in the first tier, such as whether it is HL7 compliant or not. In detail, upon 
represented schematically at 42, are additional existing receipt of a client report object request transferred according 
systems which can store non-radiology, e.g., cardiology, to the CORBA/IIOP protocol, the appropriate CRIE imple- 
related medical images or other medical information other mentation translates it into an equivalent RI system request, 
than images made uniformaly and rapidly available through 10 perhaps formatted in a HL7 compliant manner, and upon 
the medical image server of this invention. In the second tier receipt of the RI report data or response, the CRIE imple- 
is medical information server 12, which provides for uni- mentation formats it according to the defined IDL interfaces 
form and rapid distribution of information between the into a response to the client object, which is transmitted 
first-tier systems and the third-tier client systems, such as according to the CORBA/IIOP protocol over links 34. 
workstation 38. Although illustrated as a single system, as 15 CRIE 24 and CUE 32 are illustrated for purposes of 
well become apparent subsequently, medical image infor- illustration and without limitation as separate systems col- 
mation server 12 can be implemented either on more than located in Hospital 1 with the interface PAC and RI systems, 
one computer system, according to convenience and perfor- Alternatively, these interface engines may reside on a single 
mance requirements, or can be collocated on one computer system, which can be optionally collocated with medical 
system with other components of the image distribution 2 q image server 12. Also for purposes of illustration, these 
system of this invention. Also present in the middle -tier are interface engines are illustrated as each interfacing one PAC 
other object -based health-care information systems, in par- or RI system. Alternatively, each interface engine can inter- 
ticular Master Patient Index ("MPI") system 40. Third-tier face more than one PAC or RI system of the same type, 
client systems include user equipment ranging from thin separate interface engines generally being required to inter- 
clients, to standard PCs, to more powerful UNIX 25 face to different types PAC or RI systems in order to match 
workstations, as well as possibly including specialized each system *s unique interface definition to the uniform 
devices All such client devices are referred to herein as object interfaces defined in the medical image server of this 
"client workstations or simple as "workstations". invention. The instant invention includes the other imple- 
In more detail, an exemplary existing medical image mentation details that will be apparent to one of skill in the 
information system, such as might currently be found in a 30 art. 

hospital and interfaced to middle-tier medical image server Returning to FIG. 1, the remaining components of the 

12 of the present invention, is represented by equipment 14. exemplary system therein illustrated are now described in 

Illustrated therein are an existing PAC system 26 which more detail. Master Patient Index ("MPI") system, is a 

communicates to attached systems over links 28, perhaps middle-tier system, preferably present in order to obtain 

conforming to a version of the DICOM standard. The 35 relevant patient identifiers for use in the system of the 

attached systems include workstations, such as workstation present invention. Each existing first-tier PAC and RI system 

30, dedicated to PAC image display functions. typically implements patient identifiers which are unique 

Also attached is CORBA Image Interface Engine and specific to that system. Medical image server 12 may 

("CIIE") 32, which interfaces between the PAC system and • implement and require another form of patient identifiers, 

medical image server 12. Interface engine 32 functions as a 40 Finally, health-care personal using the medical image server 

server of image objects with IDL defined interfaces, which system usually easily identify patients in terms of name 

are the uniform for all attached PAC systems. Upon receipt along with certain demographic characteristics instead of 

of a client image object request transferred, for example, with details of the patient identifiers maintained by the 

according to the CORBA/IIOP protocol, the CIIE imple- various systems having patient information of interest. MPI 

mentation translates it into an equivalent PAC system 45 system 40 is an object-based middleware server present in a 

request, perhaps formatted in a DICOM compliant manner. system of this invention to translate between these forms of 

Upon receipt of the PAC image data or response, the CIIE patient identification. Although this invention is adaptable to 

implementation formats it according to the defined IDL any MPI system providing such function, in a preferred 

interface into a response to the client object, which is embodiment, MPI system 40 implements interfaces defined 

transmitted according to the CORBA/IIOP protocol over 50 by the OMG/CORBAmed Patient Identification Services 

links 34. In this manner, the specialized details of the PAC ("PIDS") and Master Patient Index IDL standard (available 

system are hidden from a client, which sees only uniform from the OMG). 

image object interfaces accessible by standard CORBA/ In the third-tier of the medical image distribution system 
HOP protocols regardless of the details of the PAC system, of this invention are client systems, such as system 38, 
such as whether it is DICOM compliant or not. The CIIE 55 presenting graphical user interfaces ("GUI") which health- 
maps the HOP protocol onto the DICOM conformant care personal use to request and view medical image infor- 
interfaces, or other proprietary interfaces, of the PAC sys- mation from the medical image distribution system. Client 
tem. systems are linked via network links 36 to medical image 
Also present as part of the exemplary medical image server 12. Preferably, links 36 implement the TCP/IP suite of 
system is RI system 18. This system also communicates over 60 protocols, and accordingly, can be a campus intranet, a 
links 20 to attached workstations, such as workstation 22, in wide-area intranet, or even the Internet. In each situation, 
a manner which is optionally be HL7 compliant. Also appropriate security protocols, for example the secured 
attached to RI system 18 is CORBAReport Interface Engine socket layer or other link encryption protocols, are used to 
("CRIE") 24, which performs a similar function for the RI insure confidentiality of medical information, 
system as CIIE 32 performs for the PAC system. In 65 In a preferred embodiment, the client GUI is implemented 
particular, CRIE interface engine 24 functions as a interface as an object-oriented interface components of which are 
for report objects with IDL defined interfaces, which are downloaded as needed from image server 12. Since only 
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Java currently provides for such download, the client GUI is 
preferably written either as a Java application or as Java 
applets in conjunction with a web-browser. The GUI inter- 
face present client objects that request information, in 
particular, medical image data, from medical image server 
12. Advantageously, therefore, client and server objects 
communicate, mediated by the ORBs, over network links 36 
using the CORBA/IIOP protocol. In the preferred 
embodiment, the Java application or applets can be down- 
loaded dynamically when a health-care user accesses the 
image distribution system and requests particular image 
data. In that manner, the GUI appropriate for the particular 
user, the particular workstation, and the particular image 
data can be made available at any user access equipment. 
Since the GUI components necessary for particular infor- 
mation or images are downloaded with the images, the most 
appropriate image display can always be assured throughout 
the system. A further advantage of the latter arrangement is 
that display of new types of information can be automati- 
cally and routinely provided for by simply downloading new 
Java-coded GUI objects for their display. 

Where all GUI components are dynamically downloaded, 
the workstation equipment can be a "thin client" with 
minimal attached resources, perhaps only a Java virtual 
machine. Alternately, where the network links to a particular 
workstation have low bandwidth, certain base GUI compo- 
nents can be cached on the workstation. In a further 
alternative, the entire GUI can be present on the workstation 
and coded in another object-oriented language, such as C++. 

Medical Image Server Middleware Software 
Architecture 

FIG. 2 illustrates the detailed software architecture of an 
exemplary preferred embodiment of the principal compo- 
nents of the image server middleware 50 for medical image 
server 12. Each illustrated component is individually 
described in the following. First, Object Request Broker 
("ORB") 52 plays a key system role in enabling the other 
objects of the system to make requests and receive responses 
in a distributed environment. One ORB is present on each 
computing system hosting the image server middleware. 
The ORB routes invocations between client and server 
objects transparently, so that these objects do not need to be 
aware of any communication details or network structure. 
Where objects reside on the same machine, requests and 
responses are routed preferably by direct procedure calls 
internal to the resident machine between the objects and the 
ORB. Where objects reside on different computing 
machines, the ORBS on the two machines communicate the 
requests and responses between the objects via the CORBA/ 
HOP. The ORB also assumes responsibility for object 
management, including, for example, object activation and 
termination, object replication, object persistence, and so 
forth. 

The client and server objects may be part of the image 
server middleware itself or may reside on other tiers of the 
system. Thus, ORB 52 participates in routing requests from 
objects in client workstations 38 to various middleware 
object servers, principally image object coordinator 54. It 
also participates in routing requests to the interface engines, 
CIIE 32 and CRIE 24, which provide object implementa- 
tions of the first-tier PAC and RI systems. 

ORB services permit the image server middleware to have 
easily scalable performance. When any particular object 
server, for example image object coordinator 54, becomes 
too highly utilized, an additional instance of the server can 
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be activated by the system ORBs and service requests 
divided between the object servers. More than two instances 
can be created if necessary. Similarly, when any particular 
computer system hosting the image server middleware 
becomes too highly utilized, additional object server 
instances can be activated on less heavily utilized computer 
systems. Conversely, when utilization falls, object server 
instances can be terminated. Dynamic routing of requests 
and responses between client and server objects on the 
various computer systems is performed automatically by 
cooperation among the system ORBS on the various 
machines. 

Before describing image object coordinator 54, which is 
central to the operation of the image server middleware, 
supporting personalization object server 58 and security 
object server 60 are described. The personalization object 
server is a CORBA object server that stores and retrieves 
profile data from the middleware database. The profile data 
can include client system profile data and user profile data. 
Client system profile data defines the characteristics of a 
particular client workstation currently accessed by a user, 
including, inter alia, hardware characteristics such as display 
resolution and network link speed, and software character- 
istics such as whether the GUI is resident or to be down- 
loaded. User profile defines user adjustable GUI preferences, 
such as display layout preferences, font sizes, and default 
medical image resolutions. 

The security object server provides security and access 
control information necessary to protect medical image data 
from unauthorized access. Security information specifies, 
inter alia, key management and encryption algorithms to be 
used in user sessions with particular client workstations over 
particular network links. Access control information 
includes, inter alia, user access control and object access 
control information. User access control identifies and legiti- 
mizes a particular user of the system, and can be by 
traditional user-id and password or by newer biometric 
techniques, such as fingerprint identification. As part of 
legitimization, this information can also specify user role 
and group, for example, attending or resident physician, 
nurse and so forth, and object access privileges, for example, 
all patients, all assigned patients, limited data for assigned 
patients, and so forth. Object access control information can 
specify, for each object or group of objects, which users or 
user groups are allowed access and what levels. Optionally, 
the security object server can also provide services to date 
and log an audit trail of each user session. 

Again referring to FIG, 2, image object coordinator 54 
plays a central role in the image server middleware. 
Generally, this object server receives client object requests 
generated by the GUI from user input transparently via ORB 
52 from the object-oriented GUI running on a client 
workstation, such as workstation 38, accessed by the user for 
medical image data or report data. This object server then, 
first, checks that the user is authorized to access the 
requested data by comparing user and object access infor- 
mation from the security object server. If access verification 
fails, an indication of this failure is returned to the client. 
Second, if the access verification succeeds, this server 
interprets these requests and forwards them, again transpar- 
ently via ORB 52, to the appropriate object interfaces 
presented by the appropriate CHE and/or CRIE. Next, 
responses from the first-tier systems are retrieved from the 
CIIE and/or the CRIE object interfaces, and the image object 
coordinator composes the responses for transmission to the 
client workstation according to the user profile preferences 
and the client workstation capabilities obtained from the 
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personalization object server. Finally, the image object coor- nicate with common protocols, for example the CORBA/ 

dinator returns the composed responses to the object- HOP protocol, they can be immediately linked and their 

oriented GUI completing a response to the user request. information made immediately available. If common proto- 

As described above, OIE 32 and CRIE 24 are interface cols are not available, a thin protocol wrapper may be 
engines which present an object-oriented interface to exist- 5 necessary to provide for communication, 
ing first-tier PAC and RI systems. Accordingly, their object Finally, web server 56 provides infrastructure, non- 
implementations receive and respond to client object object-oriented functions necessary for initiating and main- 
requests, principally from the image object coordinator, taining user sessions. At session initiation, web server 56 
using CORBA/HOP protocols between the system ORBs in downloads access information. Where the client workstation 
the middleware server computer systems. The interface 10 accesses the system through a web browser, this information 
engines communicate with the existing systems in their own, preferably includes HTML (hypertext transfer markup 
perhaps proprietary, message or command formats. language) or XML (extensible markup language) pages 
However, for PAC systems, communication is preferably defining system logon. After a session is started, this sever 
conformant to the DICOM standard, and for RI systems, the downloads GUI components as needed for the medical 
HL7 standard. There may be one or more of each of the 15 image and report information to be displayed. These typi- 
interface engines in an image server system. cally include Java applets for a web browser or a complete 

The interface engines together with the image object Java GUI application. Alternatively, where part of the GUI 

coordinator present medical image object and report object are cached or resident on a client workstation, web browser 

interfaces to client objects that are uniformly defined regard- 56 may need only to provide for session initiation, 

less of the types of the interfaced PAC and RI system. These 20 All object servers, object coordinators or interface 

object interfaces are designed to provide the basic image, engines of the image server middleware 8 are preferably 

patient, and interpretation information known in the art. One CORBA object servers implemented with defined Interface 

or more versions of these uniform object interfaces may be Definition Language interfaces. They communicate with 

available depending on image or report type. The structure each other either through the collocated ORB, if the object 

of these interfaces is preferably made available as object 25 reside in the same machine, or through multiple system 

definitions in middleware database 62. Accordingly, the GUI ORBs using the HOP protocol, if they reside across different 

interfaces at client workstations can query this database and machines on the Internet. All other properties pertinent to 

determine the structure of available image objects. CORBA object servers apply to these object servers. 

Concerning image information, the object interfaces pro- 3Q In particular, although this invention is described as if the 

vide basic medical image characteristics and image data for image server middleware included only one object server, 

radiography images, computed tomography image, mag- object coordinator, or interface engine of each type, in fact 

netic resonance images, nuclear medicine images, ultra- this middleware can include more than one entity of each of 

sound images, and so forth. Image information is identified these types. The object servers or interface engines can be 

as single frame images, groups of single frame images, 35 replicated on the same or on different machines. Such object 

multi- frame images, and so forth. Concerning patient server, object coordinator, or interface engine replication 

information, the object interfaces provide for patient iden- provides for performance scalability, as described elsewhere 

tification and demographic information, patient visit herein. 

information, patient study information, study component Importantly, it also provides for fault tolerance in the 

information, for the relation of image and patient 4Q highly mission-critical nature of medical care computer 

information, and so forth. Concerning interpretation systems. Each type of object server, object coordinator, or 

information, the object interfaces provide for results and interface engine can have one or more backup servers or 

interpretation information and for the relation of interpreta- engines of that type present in the systems. In case of a 

tion information to the other classes of information. failure of a primary object server or interface engine, 

Although, the object interfaces are described without limi- 45 requests can be immediately switched to the backup server 

tation in terms of known imaging modalities and techniques, or engine, using ORB facilities, so that the system will 

these interfaces can be extended to accommodate provide appear to function without interruption. The backup servers 

for new imaging modalities and techniques. carij optionally, be idle in the absence of a primary failure. 

Preferably the object interfaces are defined in CORBA/ Analogously, computer and communication systems can be 
IDL. Even more preferably, the IDL definitions conform to 50 replicated with object servers, object coordinators, or inter- 
present or future image and report object standards. Such face engines of each type present in each of the replicated 
standards are being defined by, inter alia, the OMG, in systems. Upon failure of a computer system or communi- 
particular by its CORBAmed task forces. cation link, the ORB infrastructure can immediately route 

The remaining elements of the middleware software requests to servers or engines on functioning systems or 

architecture are MPI (master patient index) 40 and web ss uoks > a S ain maintaining overall system availability with 

server 56. As described above, the MPI is a, preferably interruption. Further options for providing fault-tolerance 

CORBAmed standardized, object server that provides using this architecture will be apparent to those of skill in the 

unique patient identification needed for accessing existing art 

first-tier systems. When image object coordinator 54 is In addition to CORBA, this invention is adaptable to other 

presented with a user request for image or report data for an $o distributed object standards and implementations with simi- 

identified patient, it may optionally need to access MPI 40 lar functions. These alternatives include the Component 

to translate the patient identification provided by the user Object Model of the Microsoft Corp. 
into unique patient identification understandable by attached 

PAC or RI systems. Middleware Database Structure 

In addition to the MPI, other object-oriented medical 65 The middleware database, reference number 62 in FIG. 2, 
information systems can be directly linked with the image- stores data and persistent objects necessary for the function- 
server middleware. If such object-oriented system commu- ing of the image server middleware. Database 62 can be 
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implemented in a single storage device or in a combination Beginning at step 120, a user physically access a client 

of such devices. In an exemplary preferred embodiment, this workstation, and at step 122 requests download of an 

middleware database can be structured, as illustrated in FIG. access-data form by the web server. For example, an HTML 

3, into segments particular to each of software architectural home-page of the medical image server is downloaded by 

elements of the image server illustrated in FIG. 2. These are 5 the web server into a web browser when the user enters the 

segments are individually described below. web address (universal resource locator) of the image server. 

Security data segment 80 includes encryption component This page requests entry of user identification information. 
82, which stores link and session security data, such as At step 124, the user enters text or biometric identification 
encryption algorithms uses, key management protocol data and the filled-in access-data form is returned from the 
directions, and so forth. User access component 84 stores 10 web browser for user validation. The web server in coop- 
user authorization data, such as access information, for eration with the security object server performs the user 
example, userid/password, biometric signatures, or so forth, validation. At step 126, if the user is validated, the web 
user role, user access group membership, and so forth. server then downloads the initial Java applets or initial Java 
Optional object access profile component 86 stores object application modules to build the GUI for medical image or 
access information, such as the user groups, user roles, and report requests. Also downloaded is an object reference of 
so forth which are allowed access to particular objects or 15 the image object coordinator. If the user is not validated, an 
groups of objects. Accordingly, the security object server error indication is returned to the client workstation, 
using the encryption component can establish appropriate Communication between image server middleware, in 
link and session security to prevent eavesdropping. Using particular the web server, and client workstation in steps 
the user access profile component it can authorize a user to 120-126 preferably employs the hypertext transfer protocol 
access the system, and along with the object access 20 ("HTTP"), or more the preferably HTTP with the secured 
component, it can allow access only to authorized objects. socket layer ("SSL"), a well-known encryption protocol for 
This segment is preferably structured as an object-oriented securing HTTP communications. 

database. ^ t step ^28, ^ user cn t ers an image data request through 

Personalization data segment 88 includes user profiles/ ^ ob j ect . oriented client GUL Using the downloaded object 

preferences component 90, which stores user GUI 25 reference of the image ob j ect coordinator, this request is 

preferences, and optional client workstation component 92, ^ m ^ od ^ {q ^ coordinator 

which stores workstation characteristics. According the ' ^ dM ^ ^ 

personalization object server, using both components, pro- . . . & 

vides that any user can access the medicalimage distribution object coordinator upon receiving an image request first, at 

system of this invention at any workstation and receive 30 step 130 m cooperaUon with the security object server, 

image and data presentation according to the user's prefer- checks whether tms ™« 15 aphorized to access the desired 

ences and within the capabilities of the workstation that the ob i ect - At sle P 132 > ^ authorization is denied, an error 

user happens to access. This segment is also preferably indication is returned to the client workstation, 

structured as an object-oriented database. Otherwise, at step 134, the image object coordinator 

Web server data segment 94 primarily includes data 35 checks the user-supplied patient identification for adequacy, 

needed for download to client workstations. This data If it is inadequate, the MPI is consulted at step 136 in order 

includes initial presentation information stored in HTML/ to attempt to determine adequate patient identification for 

XML page component 96. The web server also downloads the first-tier PAC or RI systems storing the desired image 

appropriate components of the GUI as needed for entry of data. If adequate patient identification is not determined after 

users requests and for display of image data. These GUI one or morc attempts, perhaps including requests to the user 

components are preferably structured as Java applets for 40 for additional patient information, then an error indication is 

workstations hosting a web-browser or, alternatively, as a returned to the client workstation at step 134. 

complete Java GUI applications, and are stored in GUI Tf adequate patient identification is determined, then at 

applets component 98 or in GUI application component 100, step ^ ^ image objecl coordinator accesses lhe object 

respectively. interfaces of the appropriate CUE or CRIE. These interface 

Finally, the object infrastructure, m particular the system 45 . q &{ ^ ^ desifed of 

ORBs, requires certain data, optionally depending on the * J * r ^ ■ a * r * * 7u 

parUcular q distributed object ^mentation, in order to re P° rt data . f < om * c f cx f m * first " Ucr s y stems thcsc 

carry out request routing and object management. This data s y stems easting protocols. 

is stored in object infrastructure segment 102, and is gen- At step 140, the image object coordinator composes the 

erally represented as object definition data component 104 50 returned image data into formats and resolutions defined by 

(also known as an object definition repository) and in the personalization object server for this particular user and 

location data component 106. The object definition compo- this particular client workstation. 

nent stores data defining the object interfaces between which At step 142, the web server can be called, if necessary, to 

the system ORBs must route requests, in particular, defini- download GUI components, for example, Java applets, that 

tions of the structures of available image and report objects ss are necessary to display this particular type of image or data 

are stored here. The location data component stores object on particular type of client workstation. Finally, at step 

identifiers and other data defining current physical location 14 4 j mc com p OSC d requested data is downloaded for user 

and message routing information for performing CORBA/ viewing. 

HOP communications Communication between image server middleware and 

This invention is equally ^adaptable to 'alternative database cUeQt workstation ^ st 128 _ 144 preferablv emp ioy S the 

structures for middtewaic database 62 (of FIG. 2) data that CORBA/IIOp tocol for commumcation betwe en distrib- 

contain equivalent data and that will be apparent to those of objects. Tlicsc communications can be suitably 

skill in the art. 4 \ 

encrypted. 

General Request Processing Procedures FimUy, at step 146 the user can either request more 

A general preferred exemplary procedure for processing 65 medical image and report data or can indicate a desire to 

user requests for medical image or report data is described logoff from the system. In the latter case, at step 148 the web 

in this section with reference to steps illustrated in FIG. 4. server terminates the connection with the client workstation. 
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System Extensions 

Although the above description has been in terms of 
radiology images and report data stored on existing PAC and 
RI systems, the medical image server according to this 
invention is not limited to just radiology data. One of skill 
in the art will readily understand how to incorporate other 
medical image sources and other medical data in general. It 
will be appreciated that the medical image system of this 
invention is functionally extendible by a routine procedure. 
It has previously been described how this system of scalable 
to achieve adequate performance with appropriate cost. 

For example, cardiology-image data can readily be incor- 
porated in the following routine manner which is easily 
performed by one of skill in view of the preceding descrip- 
tion. Cardiology-image data can include single images or 
multi-image sequences useful to ascertain the functioning 
and adequacy of the cardiac vasculature and cardiac muscle. 
First, interface engines for cardiology-image data and asso- 
ciated report data are defined to provide object interfaces to 
protocols for existing cardiology data storage and commu- 
nication systems. The cardiology-image transfer standard is, 
in fact, a variant of the DICOM standard applicable to 
radiology images. 

Second, the image object coordinator is extended with 
implementation code to access the new interface engines and 
to compose cardiology images and reports for transmission 
to client workstations. The image coordinator makes avail- 
able its cardiology object definitions, as well as the radiol- 
ogy object definitions, in the object definition data compo- 
nent of the object infrastructure segment of the middleware 
database so that client workstations can query cardiology- 
image related information. Alternately, the image distribu- 
tion middleware can be extended with a separate cardiology- 
image data object coordinator that provides object 
coordinator functions similar to the existing image object 
coordinator, which thereby remains directed to radiology- 
image data. 

Finally, if new Java applets or Java applications are 
needed to display cardiology image and report information, 
they are added to the appropriate component of the web 
server data store. 

One of skill will also appreciate how the medical image 
server of this invention can be further extended to make 
available additional medical non-image information. The 
medical image distribution system would be extended, at 
least, with additional interface engines, for making available 
in a uniform object-oriented fashion the additional medical 
data stored in existing system, and with additional object 
coordinators, for retrieving and transmitting the additional 
uniform medical objects to client workstations. The addi- 
tional medical information can include, for example, infor- 
mation from laboratory computing systems or from phar- 
macy computing systems or from administrative computing 
systems. 

It should now be appreciated that the objects of the 
present invention are satisfied. While the present invention 
has been described in particular detail, it should also be 
appreciated that numerous modifications are possible within 
the intended spirit and scope of the invention. 

All references cited herein are incorporated herein by 
reference in their entirety and for all purposes to the same 
extent as if each individual publication or patent or patent 
application was specifically and individually indicated to be 
incorporated by reference in its entirety for all purposes. 

What is claimed is: 

1. A medical image distribution system for distributing 
medical images from one or more storage systems for 
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medical images to a plurality of network-attached client 
workstations, said medical image distribution system com- 
prising one or more network- attached computer systems, 
and 

s wherein each said network-attached client workstation is 
configured with a graphical interface for receiving 
medical image requests from a user, for transmitting the 
received medical image requests in an object-oriented 
format, and for displaying medical image objects 

10 received in response to the transmitted requests to the 
user, and 

wherein said one or more network- attached computer 
systems are configured with 

infrastructure modules of a distributed object system 

15 for forwarding and transmitting of object requests 

and responses, 
one or more interface engines, each said interface 
engine presenting a uniform object-oriented inter- 
face for retrieving medical image data from the 

20 existing storage systems by translating requests 

between the uniform object-oriented format and 
individual formats recognized by the storage systems 
and for returning retrieved medical image data as 
medical image objects in the uniform object-oriented 

25 structure, and 

one or more image object coordinators for receiving the 
object-oriented medical image user requests trans- 
mitted from said client workstations, for obtaining 
objects with requested medical images by forward- 

30 ing retrieval requests in the uniform object-oriented 

format to said one or more interface engines, for 
composing said obtained medical image objects 
according to preferences of the user and capabilities 
of the client workstation for display at the client 

35 workstations, and for transmitting said composed 

medical image objects to the requesting client work- 
station as a response to the transmitted object- 
oriented user requests. 

2. The system as claimed in claim 1, wherein said one or 
40 more computer systems are further configured with 

one or more report interface engines, each said report 
interface engine presenting a uniform object-oriented 
interface for retrieving medical report data associated 
with said medical image data from the existing storage 

45 systems by translating requests between the uniform 
object-oriented format and individual formats recog- 
nized by the storage systems and for returning retrieved 
medical report data as medical report objects in the 
uniform object-oriented structure, and 

so wherein said one or more image object coordinators 
further receive object-oriented medical report user 
requests associated with said medical image data trans- 
mitted from the client workstations, obtain objects with 
requested medical reports by forwarding retrieval 

55 requests in the uniform object-oriented format to said 
one or more report interface engines, compose said 
obtained medical report objects according to prefer- 
ences of the user and capabilities of the client work- 
station for display at the client workstations, and trans- 

60 mit said composed medical report objects to the 
requesting client workstation as a response to transmit- 
ted object-oriented user requests. 

3. The system as claimed in claim 1, wherein said one or 
more computer systems are further configured with a plu- 

65 rality of image object coordinators. 

4. The system as claimed in claim 1, wherein said one or 
more computer systems are further configured with one or 
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more security object servers and, wherein the security object 
servers, in response to object-oriented requests from the 
image object coordinators, check authorization of said user 
to access the medical image distribution system and to 
access requested image objects. 

5. The system as claimed in claim 1, wherein said one or 
more computer systems are further configured with one or 
more personalization object servers for providing to said 
image object coordinators information for composing said 
image objects according to interface preferences of the user 
and according to capabilities of the client workstation. 

6. The system as claimed in claim 1, wherein said one or 
more computer systems are further configured with one or 
more web servers for downloading access-data forms and 
object-oriented graphical interface modules to client work- 
stations. 

7. The system as claimed in claim 1, wherein said medical 
image data comprises radiology image data. 

8. The system as claimed in claim 1, wherein said medical 
image data comprises cardiology image data. 

9. The system as claimed in claim 8, wherein said one or 
more computer systems are further configured with one or 
more cardiology interface engines, each said cardiology 
interface engine presenting a uniform object-oriented inter- 
face for retrieving cardiology image data from the existing 
storage systems by translating requests between the uniform 
object-oriented format and individual formats recognized by 
the storage systems and for returning retrieved cardiology 
image data as cardiology image objects in the uniform 
object-oriented structure. 

10. The system as claimed in claim 9, wherein said one or 
more computer systems are further configured with one or 
more cardiology image object coordinators for receiving 
object-oriented cardiology image user requests transmitted 
from said client workstations, for obtaining objects with 
requested cardiology images by forwarding retrieval 
requests in the uniform object-oriented format to said one or 
more cardiology interface engines, for composing said 
obtained cardiology image objects according to preferences 
of the user and capabilities of the client workstation for 
display at the client workstations, and for transmitting said 
composed cardiology image objects to the requesting client 
workstation as a response to transmitted object-oriented user 
requests. 

11. The system as claimed in claim 9 further comprising 
a middleware database for storing persistent data comprising 
definitions of said uniform object-oriented formats of said 
cardiology image objects. 

12. The system as claimed in claim 1, further comprising 
a middleware database for storing persistent data and 
objects. 

13. The system as claimed in claim 12 wherein said 
middleware database data further comprises definitions of 
said uniform object-oriented formats of said medical image 
objects. 

14. The system of claim 12 wherein said middleware 
database data further comprises user preferences and client 
workstation capabilities. 

15. The system as claimed in claim 1, wherein said one or 
more computer systems are further configured with one or 
more additional interface engines for presenting a uniform 
object-oriented interface for retrieving additional medical 
data from the existing storage systems as additional medical 
data objects, and one or more additional object coordinators 
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for coordinating transmission of additional medical data 
objects to requesting graphical interfaces, 

16. Hie system as claimed in claim 15, wherein said 
additional medical data comprises pharmacy data or medical 

5 laboratory data. 

17. The system of claim 1 wherein the uniform object- 
oriented format and the distributed object system are 
described by the CORBA standard. 

18. The system of claim 1 wherein the individual formats 
recognized by the storage system comprises a format 
described by the DICOM standard. 

19. The system of claim 1 wherein said one or more 
computer systems are further configured with one or more 
master patient index object servers, and wherein the master 
patient index object servers in response to object-oriented 

15 requests from the image object coordinators provide patient 
identification. 

20. A method for medical image distribution by one or 
more network-attached computer systems from one or more 
storage systems for medical images to a user at a network- 

20 attached client workstation comprising: 

receiving a user request at a client workstation for a 

medical image, 
transmitting the received user request for the medical 
image in an object-oriented format from the client 
25 workstation to an image object coordinator at the one or 
more network-attached computer systems, 
forwarding a retrieval request for the requested medical 
image in a uniform object-oriented format from the 
3Q image object coordinator to an interface engine at the 
one or more network-attached computer systems, 
retrieving the requested medical image data for the 
requested medical image by the interface engine from 
one of said existing storage systems, wherein the 
35 retrieving further comprises translating requests 
between the uniform object-oriented format and indi- 
vidual formats recognized by the storage systems, 
composing medical image objects received by the image 
object coordinator from the interface engine in the 
40 uniform object-oriented format according to prefer- 
ences of the user and capabilities of the client 
workstation, 

transmitting said composed medical image object by the 
image object coordinator to the client workstation as a 
45 response to the transmitted object-oriented user 
request, and 

displaying by the client workstation of said transmitted 
composed medical image objects to the user. 

21. The method of claim 20 further comprising, prior to 
50 the step of forwarding a retrieval request, a step of request- 
ing a security object server to check identification provided 
by the user to authorize the user to obtain medical images 
and of checking the authorization of the user to access the 
requested medical image object. 

55 22. The method of claim 20 further comprising, prior to 
the step of forwarding a retrieval request, a step of request- 
ing a master patient index object server to obtain patient 
identification. 

23. The method of claim 20 further comprising, prior to 
60 the step of receiving a user request, a step of downloading 
object-oriented graphical interface modules to the client 
workstation. 
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